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ABSTRACT 


Location awareness is invaluable to the military eommander. Any applieation 
that can accurately deliver this serviee is highly desirable. Being able to extraet aecurate 
distanees is the first step towards developing a proposed 802.11 loeal area positioning 
system. This thesis explores a number of different methods of using 802.11 to eapture 
physieal distanee separation between mobile stations. The first method of measuring 
distanee, involves using 802.11 round trip signal times. Round trip signal times are 
determined from a transmitter to a reeeiver and baek, and are used with the speed of light 
to measure distanee between the nodes. Another method of using 802.11 to measure 
distance involves using signal strength measurements and a elient-server arrangement. 
Distanees can be extracted by extrapolating through a range of signal strength 
measurements. Beeause signal strength is a measurement of power, its behavior is 
governed by the inverse-square law. If environmental variables, sueh as humidity and RF 
interference do not signifieantly ehange, a line graph of signal strength measurements 
versus distanee ean be used to determine positions under these eonstant eonditions. 
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I. 


INTRODUCTION 


A. BACKGROUND 


Positioning systems in general are often eategorized into three groups: global 
systems, wide-area systems that rely on eellular teehnologies and loeal area 802.11 
positioning system. The Global Positioning System (GPS) for example, is a global 
system. It is a satellite based navigation system that provides aecurate and reliable 
positioning information with world wide eoverage. GPS however is unreliable in many 
urban areas, where line-of-sight aeeess to satellites is often obstrueted by satellite signal 
impenetrable struetures sueh as large buildings. For indoor positioning, GPS serves little 
value. Additionally, separate hardware is required to enable GPS serviees. In areas 
where GPS is ineffeetive, wireless positional systems that use 802.11 protoeols may be 
used to deliver positioning serviees. Positioning is eommon for a number of wide area 
systems, such as systems using cellular technologies; however the high cost of setting up 
a cellular infrastructure and the inaccessibility to proprietary cellular system codes makes 
is impractical for many wireless positioning applications. This thesis will focus on local 
area 802.11 positional systems. 

Location awareness is invaluable to the military commander and any application 
that can accurately deliver this service is highly desirable. Positioning and tracking 
systems provide military commanders an important tool to plan, coordinate, and assess 
tactical operations. There are a number of different military applications of 802.11 based 
positional systems. A wireless enabled device could be connected to a Voice over IP 
(VoIP) phone to provide emergency distress location services. 802.11 could also be used 
to map out an area of operations to provide location services and directions as tactical 
waypoints. With radio frequency identification (RFID) technology, 802.11 could be used 
to track people and equipment for mission planning. The positioning system could be 
embedded within a wireless mesh network to extend range through backhaul connections. 
For example, a couple of root nodes are connected to the primary network or directly to 
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the Internet. The mesh elients are eonneeted to rest of the network, thus extending 
positioning information to servers that ean proeess eolleeted positional data. 

Currently, there are a number of different wireless positional systems that are 
available, eaeh of whieh use different 802.11 methods to provide positioning serviees. 
For example. Skyhook Wireless is a company that develops software which determines 
positioning information using a nationwide network of known Wi-Fi access points. 
Skyhook enabled devices collect the MAC address identification for every access point in 
its range, and compares the identification to a database that contains known locations for 
these access points. Using these known locations. Skyhook determines location based on 
its relative position to the known access points. These developers claim positional 
accuracy to within 20 to 40 meters, particularly in metropolitan areas where there is a 
large network of deployed wireless access points which are stationed close together. 

B. PURPOSE 


Being able to extract accurate distances is the first step towards developing a 
proposed 802.11 local area positioning system. This thesis explores a number of 
different methods of using 802.11 to capture physical distance separation between mobile 
stations. The first method of measuring distance, involves using 802.11 round trip signal 
times (RTT). RTT is determined from a transmitter to a receiver and back, and is used 
with the speed of light to measure distance between the nodes. The distance can then be 
imported into a trilateration algorithm to calculate positional information. For example, 
from Figure 1 below, relative location of a mobile client (B) can be accurately 
determined using a two dimensional grid. Three stationary wireless access points (PI, 
P2, and P3) determine respective distances (rl, r2, and r3) to the mobile client. Knowing 
rl limits the possible locations around the circumference of the PI circle. Knowing rl 
and r2, narrows the possible locations down to either point A or point B. Knowing rl, r2 
and r3, it is possible then to trilaterate the position of the mobile client to point B. 
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Figure 1. Trilateration Schematic. 

Placing this grid over an x-y Cartesian coordinate system, relative positions can 
be further defined using PI as an anchor, located for example at position (0,0) on the x, y 
coordinate plane. Once trilateration is accomplished, the distance from PI to B is equal 
to rl, which then could be separated into x and y components. 

An 802.11 access point can be used as a source for the RTT signal. For wireless 
local area networks (LANs), the beacon frame provides management functionality used 
to establish and maintain communications between the access point and a wireless 
station. Generally, the beacon intervals are set at about 100 ms, but the intervals can be 
controlled. By inserting a timer routine just prior to the transmission of the frame and 
immediately after the return of a response to the beacon frame, RTFs can be calculated. 
Distance between the nodes can then be found using pre-determined system processing 
times and theoretical propagation times for the signal. 

Another method of using 802.11 to measure distance involves using signal 
strength measurements and a client-server arrangement. Distances can be extracted by 
extrapolating through a range of signal strength measurements. Because signal strength 
is a measurement of power, its behavior is governed by the inverse-square law. If 
environmental variables, such as humidity and RF interference do not significantly 
change, a line graph of signal strength measurements versus distance can be used to 
determine positions under these constant conditions. 
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C. RESEARCH QUESTIONS 


1. Is it possible to take advantage of 802.11 eapabilities in developing a 
system to eapture physieal distanee separations between wireless nodes? 

2. Can distanees obtained through 802.11 methods be used with trilateration 
to aecurately and preeisely determine positional information? 

3. Can determining the round trip time a wireless signal sent from wireless 
stations effectively be used to determine distance? 

4. What is the relative impact of system processing time on round trip time 
calculations? Are the differences significantly large enough that it 
negatively impacts 802.11 distance measurements? 

5. What are the statistical spread of round trip time propagation delay 
between the transmitter and receiver? Are the spread large enough that 
they prevent accurate determination of distances? 

6. Are the processing times for signals that originate higher in the protocol 
stack significantly large enough that it prevents accurate distance 
measurements using round trip times? 

7. How does the time it takes for a network interface card to modulate a 
transmission and reception signal contribute to system processing times? 

8. How does 802.11 round trip time compare with signal strengths in 
determining distances? 

9. What are the spatial limitations of 802.11 positioning systems? 

10. What are the environmental variables that have the greatest impact on 
802.11 signals? 

D. SCOPE AND METHODOLOGY 


The first step towards developing a wireless positioning system involves using 
802.11 to capture distance values between wireless stations. One method that is 
investigated uses RTTs for 802.11 packets. Network packet signaling involves inter- 
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process communications through sockets. The client, process one, establishes a 
conneetion to the server, process two, through the socket. A timer mechanism, such as 
Java’s nanotimer API, is used to measure how long it takes for a paeket to complete a 
round trip from the client to server and back. Using the general laws of RF propagation 
over the air, it is expected that distances can be determined. 

Using network packets however adds an enormous overhead cost in terms of how 
long it takes to process the signal as it moves through the protocol stack. If the 
processing times are large enough, accurate distance measurements may be overwhelmed 
by the large processing time. An alternative method of using 802.11 to measure distance 
is also investigated. In this method, layer two beaeon frames are used. One praetical 
way of automating this setup involves using an 802.11 access point and establishing an 
infrastrueture network. In creating an infrastructure network, the periodic beacon 
transmissions from the access point may be used as a source for the round trip signals. 
For this thesis a mobile laptop running Linux Fedora Core 4 was configured to serve as 
an aecess point. 

Using signal strengths may also be used to measure distance. The laws of RF 
propagation, such as the inverse-square law for power can be used to extrapolate a finite 
set of signal strength measurements. These extrapolated values ean then be used to 
predict distances. 

E. ORGANIZATION OF THE THESIS 


The chapters in this thesis are arranged according to the following topics. Chapter 
II is an overview of basic wireless coneepts that are important to the work involved with 
this thesis. The chapter is not meant to be comprehensive, but rather it touches upon key 
points that are relevant to this paper. Chapter III explores the use of packet round trip 
times, using Java sockets, as a method of determining position. The results of this 
chapter establishes the foundation for Chapter IV whieh discusses the possibility of using 
automated 802.11 layer two beacon transmissions from a wireless aceess point as the 
signaling mechanism for round-trip time calculations. This chapter will also detail the 
setup and eonfiguration of a Linux based wireless access point. Chapter V discusses a 
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method of positioning using wireless signal strengths. Chapter VI eompletes this thesis 
with overarching conclusions and recommendations for future work. 
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II. THE 802.11 PROTOCOL AND WI-FI SERVICES 


A. THE 802.11 PROTOCOL 


A discussion on certain details of the 802.11 protocol and Wi-Fi services is 
necessary to understand the methodologies used throughout this thesis. This ehapter 
provides a glanee at certain aspeets of the 802.11 protoeol and Wi-Fi services that are 
important to this thesis and is not meant to be a complete report on the operation of the 
802.11 protoeols and Wi-Fi services. For further details on both standards, the sourees 
loeated in the appendix may be referred to for more specifie information. 

Wireless LAN teehnology is dominated by 802.11 protocols, which refer to a 
group of speeifioations that was approved by the IEEE in 1997. These specifieations are 
important because they establish the radio standards necessary for over the air 
eommunieations between wireless nodes and aeeess point base stations, and 
communications between different wireless nodes. 

802.11 is a link layer protocol, which is responsible for transferring data between 
adjaeent nodes. The link layer establishes the funetionality of sending data frames as 
well as the proeedural arrangements to establish eommunieations between the nodes. 
The link layer also provides error deteetion and eorrection meehanisms to maintain the 
integrity of the data frames. 

Beeause link layers are only responsible for getting a data frame from a partieular 
souree to an adjacent destination, link layer addressing is extremely simple. Complieated 
routing tables are not neeessary to move data frames because the link layer is not 
responsible for sending information to more than one place. It just has to establish 
eommunieations with a single destination node. Communieation with this single 
destination node however ean occur over multiple ehannels beeause 802.11 also defines 
multiple-aeeess through the Media Aeeess Control (MAC) sub layer. The MAC sub 
layer allows communieation to take plaee within a multipoint topology by implementing 
addressing and ehannel access eontrols. This allows nodes that are physically connected 
to same aeeess point to share resourees without the need for complieated routing 
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mechanisms. 802.11 also serves as a physical layer standard, because it implements the 
mechanisms for transfer of data bits through radio transceivers that connect network 
nodes. 

Since its inception in 1997, the 802.11 standard has added a number of major 
improvements. The most significant modifications occurred in the middle of 2003 with 
the development of the 802. llg standard. Changes included a higher data rate, medium 
access processes, and modulation techniques. 802.llg extends the capabilities of the 
802.11b protocol and their technologies are compatible because they both operate in the 
2.4 GHz range. This means that 802.11b and 802.1 Ig devices can operate with one 
another however the performance limitations are restricted by 802.11b data rates. 
802.1 Ig is able to attain higher rates because it uses Orthogonal Frequency-Division 
Multiplexing (OFDM) modulation, the same method found in the 802.11a protocol. In 
January 2004 a committee was formed to address required standards for 802.1 In 
amendments, which included proposals for maximum data rates approaching 540Mbs, a 
rate ten times faster than the 802.1 Ig standard. It is expected that the 802.1 In standard 
will be fully ratified by the end of 2007. Table 1 below lists typical performance 
characteristics for three commonly found 802.11 protocols. 


Protocol 

Op. Frequency 

Data Rate (Max) 

Ob .served Range 

802.11a 

5 GHz 

54 Mbit/s 

200 ft 

802.11b 

2.4 GHz 

11 Mbit/s 

200 ft 

802. llg 

2.4 GHz 

54 Mbit/s 

600 ft 


Figure 2. Common 802.11 Protocols 

The 802.11 specifications operate over the unlicensed band portion of the radio 
spectrum, which is reserved internationally for industrial, scientific and medical (ISM) 
non-commercial uses. Recently this portion of the electromagnetic field RF field has 
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been widely used in a number of different license free applications such as Wi-Fi, 
Bluetooth and wireless telephone sets over the 2.4 GHz and 5 GHz bands. However 
different countries may have slight modifications to these operational communications 
band. For example, in the United States the FCC is the regulatory body responsible for 
establishing the rules for use of wireless communications over these RF bands. 

B. WI-FI CERTIFICATION 


802.11 standards do not address Wi-Fi certifications. Wi-Fi certification is 
granted to those wireless equipment that meet interoperability testing requirements as 
defined by the Wi-Fi Alliance (http://www.wi-fi.org/index.php). Certification ensures 
that equipment that are manufactured by different vendors are able to work together. 
Therefore, wireless equipment that adheres to 802.11 standards may or may not be Wi-Fi 
certified. For the purpose of this thesis, references to 802.11 technologies infer Wi-Fi 
compliance. 

C. SERVICE SETS 


The typical Wi-Fi arrangement includes at least two nodes. The nodes may be all 
wireless clients talking to each other over ad hoc connections or it may include access 
points. The nodes that establish communications directly with each other forms a Basic 
Service Set (BSS), Figure 3, and is recognized by an identification code called the 
BSSID. The BSSID is derived from the node’s MAC address. The BSS can be either an 
infrastructure based or ad-hoc based BSS. The infrastructure BSS (InfBSS) relies on 
access points as communication switches. Ad-hoc based BSS, or Independent BSS 
(IBSS) are comprised solely of wireless nodes that communicate peer to peer. 
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Extended Service Sets (ESS) are used to establish communications between nodes 
from one BSS to another BSS, Eigure 4. Eor the scope of this thesis, communications 
occur over the peer to peer BSS domain. 



D. WI-FI SERVICES 


Wi-Ei standards establish nine basic management services: Association, 
Disassociation, and Re-association, Authentication, De-authentication and Privacy, 
Packet Delivery and Distribution, and Integration. The management services are 
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responsible for the initial establishment, maintenance and security of communications. 
This thesis however primarily focuses on the association and packet delivery services. 

The MAC layer is responsible for the rules that govern association services. The 
rules establish the procedures necessary for discovery and connection of a node to an 
access point or another peer node. Before association takes place a wireless node is 
constantly scanning for wireless networks to connect. The node is aware of available 
networks through beacon advertisements. Beacons are broadcast frames used to 
advertise the location of nodes. The frames contain the Service Set Identifier (SSID) 
which is a 32 bit text string used as a unique identifier for both the BSSs and ESSs. The 
beacons are sent periodically according to intervals established by the user; however 100 
ms is usually the default setting. The periodic transmissions ensure that nodes are able to 
synchronize with one another for functions such as association and power management 
operations. Association to a BSS or IBSS occurs through a three phase process as 
outlined by the IEEE. Phase I is the un-associated state, phase 2 is authenticated but un¬ 
associated state and phase 3 is the associated phase. In order to authenticate the node 
first sends an authentication request. If security is enabled, the access point or peer node 
responds with a shared key challenge. The node enters phase 2 after it successfully 
satisfies the challenge request. Once authenticated the node sends an association request, 
which is a frame that includes information such as the SSID of the requested network and 
management information such as its supported data rate. The node is associated with the 
network once it receives an association acceptance frame and is then free to transmit data. 
Since this thesis involves open authentication (no authentication), phase 2 is not 
applicable. 

E. FRAME COLLISIONS 


Erames transmitted over the air are susceptible to collisions, similar to frames 
transmitted over the wire. Because it is impractical to implement a collision detection 
protocol, such as that used in Ethernet, Wi-Ei standards establish an avoidance protocol 
to minimize loss of frames due to collisions. Collision detection is not used for over the 
air transmissions because of two particular situations. 
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The first situation, Figure 5, involves a transmitter that is incapable of hearing a 
second transmitter, because of extended range. Both transmitters however are in range of 
the receiver, but collision detection is not possible because the first transmitter does not 
know when the other transmitter is sending frames. 


Transmitter A Receiver Transmitters 

Figures. Inaudible Transmitters 

A second situation involves a topology similar to that in Figure 6 below. The 
Transmitter-Receiver pairs A and B are in range of one another, the Transmitters A and B 
are in range of one another but the Transmitter A and Receiver B (and Transmitter B and 
Receiver A) are not in range of each other. When Transmitter A or B attempts to send 
frames when the other Transmitter is sending frames, carrier sense prevents simultaneous 
transmission, even though the intent is to send frames to different destinations. 




F. CSMA-CA 


Wi-Fi uses a Carrier Sense Multiple Access with Collision Avoidance 
(CSMA/CA) protocol because collision detection is not practical for most Wi-Fi 
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hardware. This is because most Wi-Fi network cards have only a single antennae and full 
duplex operation is not possible. The antennae can either send or receive at a given 
moment in time, but it cannot do both simultaneously. Full-duplex cards are available 
but extremely expensive to manufacture and therefore collision avoidance protocols are 
more commonly found in Wi-Fi gear. 

G. RTS-CTS CONTROL FRAMES 

CSMA/CA is an 802.11 control service that is responsible for the delivery of 
frames between nodes. Before a node begins transmitting a frame, it listens for activity 
(carrier sense) to determine if a channel is available for sending data. An available 
channel indicates that the channel is clear of transmissions and that it has been reserved 
for transmission. This is achieved using Request To Send (RTS) and Clear To Send 
(CTS) frames that are sent between the source node, the destination node, and all audible 
nodes in range. Wi-Fi CSMA/CA protocols use RTS and CTS frames for collision 
management. RTS and CTS frames are 802.11 standards designed to address issues 
related to performance of wireless systems, such as the problem associated with 
neighboring transmitters. An RTS frame is sent from the source node to the destination 
node. The destination replies by broadcasting CTS frames, which are used to inform the 
source node that it is ready to receive data. Additionally the CTS frames are designed to 
instruct other audible nodes to wait after an established delay period before attempting to 
send frames. Transmission of data frames begins after the source node receives the CTS 
response. The receiver sends an acknowledgment to the source, indicating completion if 
error checking is successful. If the node senses that the medium is being occupied, it 
starts a timer that randomly establishes a delay before it again attempts to sense the 
medium for availability. During the RTS-CTS exchange, if frames are dropped or lost, 
the sequence begins again from the start after the expiration of a random delay time. 
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H. INTERFERENCE IN THE ISM RANGE 


Operation of Wi-Fi in the ISM range introduces a number of problems related to 
RF interference since the ISM range includes a large number of different commercially 
available devices that ignore 802.11 protocols. In the 2.4 and 5 GHz range it is common 
for devices such as wireless telephones, microwave ovens, and other 802.11 devices 
operating on the same channel to interfere with the primary signal. Because Wi-Fi data 
packets are sent in accordance with collision avoidance protocols, delivery of data can 
only occur when the transmission medium is available. This means when one node is 
transmitting, a second node must wait until the channel is idle before it can begin 
transmission. If a noncompliant device is transmitting over a frequency being used by an 
802.11 device, the 802.11 device may have to wait unnecessarily until the medium 
becomes available. 

Another situation occurs when an 802.11 device is in the middle of transmitting 
data. Because a noncompliant wireless device does not have to operate in accordance 
with 802.11 rules, it does not adhere to collision avoidance protocols. If the 
noncompliant device begins transmission while an 802.11 device is transmitting, 
interference signals are introduced which can lead to dropped packets. If the packets 
arrive at the destination node, the data may be corrupted. If the source does not receive a 
successfully acknowledgement frame it continues to send packets which adds additional 
load to the network medium. 

1. 802.11 CHANNELS 


Splitting the network frequencies into channels alleviates the problem of 
interference between nearby 802.11 devices. For example, three channels, 1, 6, and 11 
are used for the 802.1 Ib/g standard in the United States. A channel is configured for the 
access point or an ad-hoc node. A node that wishes to establish communications 
automatically tunes its radio to the chosen channel to establish association. Tuning 
however depends of the strength of a signal. Given two access points that are in the 
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vicinity of one another, and both are assigned the same channel, tuning will bind to the 
access point that has the higher signal strength. 

Eleven ehannels, separated by 5 MHz, are actually assigned to the 802.1 Ib/g 
standard. However beeause a typieal 802.1 Ib/g transmission uses 30 MHz of bandwidth, 
the number of available channels is effectively reduced to three channels in order to 
eliminate signal overlap. Figures 7 and 8. Fourteen ehannels are assigned to the 802.11a 
standard. 
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III. DETERMINING DISTANCES USING PACKET ROUND TRIP 

TIMES 

A. INTRODUCTION 


Experiments were conducted to determine the possibility of using round trip 
packet propagation times between two wireless nodes to compute distance. The setup 
involves a client that initiates a packet transmission and a server which captures the 
packet and re-routes the original packet back to the client, Figure 9. At the client, a timer 
API is used to measure total round trip time, which is then used along with the physical 
propagation property of RE transmissions over the air to extract processing time intrinsic 
to the given system configuration. Once an estimate of total processing time is obtained, 
it can then be used along with measured round trip times to compute distances as the 
nodes are moved at varying distances from one another. 



Propagation 
Time 1 



► 


Processing 
Time 1 


Processing 
Time 2 


Propagation 
Time 2 


Total Time = Proc Time 1 + Proc Time 2 + Prop Time 1 + Prop Time 2 


Figure 9. Round Trip Time Schematic 
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B. NETWORKING SOCKETS 


A networking socket is a software endpoint that establishes bidirectional 
communication between a server program and one or more client programs. The socket 
associates the server program with a specific hardware port on the machine where it runs 
so any client program anywhere in the network with a socket associated with that same 
port can communicate with the server program. 

Networking sockets reside at the Session Layer of the OSI model, Figure 10. 



The Session Layer is positioned between the application-oriented, upper layers and the 
real-time data communication, lower layers. The Session Layer provides services for 
managing and controlling data flow between two computers. As part of this layer, 
networking sockets provide an abstraction that hides the complexities of transmitting the 
bits and bytes of information. 
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c. 


CLIENT-SERVER MODEL 


The client-server model provides a convenient way to connect processes that are 
physically separated. A server program typically provides resources to a network of 
client programs. Client programs send requests to the server program and the server 
program responds to each request. Most network communication uses the client-server 
model. The client and the server are the two processes which will be communicating 
with each other. The client requests for service provided by the server. Bear in mind that 
the client needs to know of the existence of and the address of the server, but the server 
does not need to know the address of or even the existence of the client prior to the 
connection being established. Once a connection is established, both sides can send and 
receive information. 

The procedures for establishing a connection are different for the client and the 
server, but involve the creation of a networking socket. Both the client and server create 
their own respective sockets. 

On the client side, the following steps are taken; create a socket with the socket() 
system call, connect the socket to the address of the server using the connect() system 
call, and finally, send and receive data. On the server side, the following steps are taken; 
create a socket with the socket() system call, bind the socket to an address using the 
bind() system call, listen for connections with the listenQ system call, accept a connection 
with the acceptO system call, and finally, send and receive data . 

D. SOCKET TYPES 


The two widely used socket types are stream sockets and datagram sockets. Each 
uses its own communications protocol. Stream sockets use Transmission Control 
Protocol (TCP) and datagram sockets use User Datagram Protocol (UDP). Stream 
sockets use a reliable, full duplex, connection-oriented means of communications, while 
datagram sockets use unreliable, bidirectional data flow. Datagram sockets, because of 
its reliance on UDP, are referred to as connectionless sockets. When a networking socket 
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is created, the program has to provide the serviee name, the protoeol, and port number. 
Figure 11 shows how a client’s network soeket interacts with the server’s network socket. 



E. PACKET PROPAGATION TIMES 


For this experiment, programming was performed in Java. Two Java classes were 
ereated, NanoServer and NanoClient. The NanoServer class designated one of the 
wireless nodes as a server and used port 9876 to wait for UDP packets from the elient. 
As soon as the server reeeived a paeket from the client, it checked the payload to ensure 
that the UDP paeket came from the elient running the NanoClient elass. The following is 
a fragment of the NanoServer class code. Appendix A. 

class NanoServer { 

public static void main(String [] args) throws Exception { 

// Port Number 

DatagramSocket serverSocket = new DatagramSocket(9876); 
while (true) { 
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//Receive Packet 

DatagramPacket receivePacket = new 
DatagramPacket(receiveData, receiveData. length); 
serverSocket. receive(receivePacket); 

sendData = entry.getBytesQ; 

// set to IP Address 
DatagramPacket sendPacket = new 
DatagramPacket (sendData, sendData. length, IP Address, port); 
serverSocket.send(sendPacket); } } } 

The following is a fragment of the NanoClient elass eode, Appendix A. The 
NanoClient class establishes a Datagram socket for the UDP Client-Server. It ensures 
minimal overhead during processing packets between the two nodes. Since Java provides 
a nanosecond counter, this feature was used in the algorithm. The method nanoTime( ) 
was started as soon as the UDP packet left the client. As soon as the UDP packet was 
received from the server, the nanoTime( ) method is invoked again. The difference was 
recorded in a data structure called Statistics object. The Statistics object provided 
histograms and calculation of the mean. 

public class NanoClient{ 

public static void main(String args[] ){ 

SimpleStats ss = new SimpleStats(); 

Histogram hist = new Histogram ("Output", 0, 2600000, 100); 
for (int i=0; i <= 1000; i++)( 
try { 

DatagramSocket clientSocket = new DatagramSocket(); 

// UDP IP address and Port Number 

DatagramPacket sendPacket =new 
DatagramPacket(sendData, sendData. length. 
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IP Address, 9876); 

// Send Packet 

clientSocket.send(sendPacket); 
long start = System.nanoTimeQ; 

// Start Timer 

System.out.println (start); 

DatagramPacket receivePacket = new 
// UDP RECEIVE 
DatagramPacket(receiveData, 
receiveData. length); 

// Start Timer 

long stop = System.nanoTimeO; 
long difference = stop-start; 

System.out.println (dijference); //Difference 

Measurements were eondueted in aeeordanee with the following proeedures: 

1. Estimate Theoretieal Propagation Time (T thjrop) given a known distance 
between the client and server. This thesis uses ideal RF propagation of 
packets over the air to compute theoretical propagation times. 

T th _prop = Prop I + Prop 2 =2 * (3 *10^ m/s) * distance 

2. Measure Round Trip Time (RTT) using timer API routine. The measured 
RTT is equal to the combined total of processing and propagation times 
for the client and server. 

RTT = Total Time = Proc I + Proc 2 + Prop I + Prop 2 
RTT = Proc I + Proc 2 + T thjwp 
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3. Compute Total Processing Time (Tproc). Tproc does not change if the 
system configuration does not change. For example, Tproc will increase or 
decrease depending on whether a new process is started or a running 
process is stopped. Tproc is then used in future measurements, along with 
measured RTT at varying client server positions to compute distance. 


Tproc = Proc 1 + Proc 2 


RTT - Tproc + Tt 


th _prop 


Tproc ~ RTT - Tt 


th _prop 


4. Assuming Tproc remains constant, determine the distance between wireless 
nodes, using measured RTTs. 


Tth _prop 


= RTT- 


T 

^ proc 


2 * f3 *10^ m/s) * distance = RTT - Tproc 
distance = (RTT - Tproc) / 2 * (3 * 10^ m/s) 


F. DATA AND ANALYSIS 


Figures 12 and 13 show the lowest and highest readings generated. For 30 
executions of the Java application, the outcome was a mean of 2.6 ms. 
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Figure 12. Sample run number one at 158 meters 



Figure 13. Sample run number two at 158 meters 
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Since most of the data values clustered around 1.0 ms, a fdter was applied to 
purge the outliers. Outliers are due to radio signals not taking the shortest path between 
the client and the server. For example, since the wireless eard is omni-directional a 
signal may be initially sent away from the reeeiver, bounee off a refleetor a number of 
times before reaehing the intended target. Because of this effect, a signals propagation 
time is higher than an ideal situation where a signal takes a straight path from the 
transmitter to the reeeiver. With the filter ineorporated in the Java code, readings were 
again taken, as seen in Figures 14 and 15. 
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Figure 14. Sample run number one at 158 meters with filtering 
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Figure 15. Sample run number two at 158 meters with filtering 


o 

Beeause radio waves travel at 3 x 10 m/s, the theoretieal round trip time for 158 
meters is 1.1 ps. However when the Java applieation was run 30 times, a mean of 1.0 ms 
was obtained, yielding a differenee in magnitude of over 1,000 times that of the 
theoretieal propagation time. A number of reasons ean be attributed to this large 
differenee; ineluding, the large proeessing time that it takes for the wireless eard to 
modulate the signal, the time it takes the OS to serviee other proeesses taking plaee 
before it serviees the networking data paekets, and the large proeessing times attributed to 
the operations of the Java Virtual Maehine (JVM). 

Measurements were then performed at 83 meters. Figures 16-17, with the 
intention of determining whether it is possible to resolve ehanges in distanee using this 
methodology. Sinee the distanee between the elient and server is halved, a eorresponding 
deerease in RTF is antieipated. 
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Figure 16. Sample run number one at 83 meters with filtering 



Figure 17. Sample run number two at 83 meters with filtering 


The results at 83 meters however suggest otherwise. From the histograms there is 
very little difference in RTFs from times obtained at 158 meters, with the average RTF at 
83 meters resting at 1.0 ms. The results however are aligned with the conclusion that 
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signal propagation times are easily overwhelmed by large proeessing times. A decrease 
in 83 meters corresponds to a decrease in 0.5 ps RTT, which goes undetected because 
measured RTTs are 1,000 times larger. 
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IV. DETERMINING DISTANCES USING BEACON ROUND TRIP 

TIMES 


A. INTRODUCTION 


An 802.11 setup used to determine distances using layer four TCP packets and IP- 
based addressing is not practicable to measure distances of any value because of the 
limitations imposed by markedly high processing times. Rather, in order to trim down 
the time it takes to process TCP/IP packets, it is necessary to capture link layer beacon 
frame propagation times instead. 

B. PACKET ENCAPSULATION 


Figure 19 below illustrates the simple encapsulation process for a chunk of data 
that initiates at the application layer. 



Normally data is created at the top of the protocol stack, or the application layer. The 
application data is then sent down the stack to be processed by encapsulating the data 
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with additional protocol information, or headers. Eaeh layer possesses different header 
information relevant to the functionality of that particular layer. As an example, the 
network layer uses source and destination IP addresses as part of its header information. 
This information is worthless to the other protocol layers, so the eneapsulation proeess 
effeetively isolates or obseures the header data until the paeket arrives at a layer that can 
use the information, for the ease of layer three, the networking layer uses this information 
to route paekets from a network souree node to a destination node. The higher level 
information is stripped to expose pertinent data. Whatever remains underneath is used by 
the protoeols to move or proeess the data to the next layer. Paekets that make numerous 
trips through routers go through a repeated proeess of stripping and eneapsulation, whieh 
signifieantly adds to the system proeessing time. At the core of the eneapsulated paeket 
is the data, and not until all header layers have been stripped that the data is available to 
the destination applieation. 

C. THE BEACON FRAME 


Beacons are layer two frames that are important for a number of reasons. During 
passive searehes, a node that wishes to assoeiate to a partieular BSS uses the beaeon to 
determine the identity of the aeeess point through the SSID. 

Additionally, the beaeons are important beeause they eontain bits that help 
manage power saving funetions. Beeause wireless nodes are often running on a battery 
source, it is essential that searee power resourees as effieiently handled. 802.11 sleep 
mode allows a node that is sitting idle to power down until there is a resumption of 
aetivity. During a period of inaetivity, sleep mode ensures that nodes do not lose 
important data. The access point is responsible for sleep mode beeause it maintains a 
reeord of whieh nodes have sleep mode enabled. For these nodes, the aeeess point 
buffers data paekets until a polling request is initiated by the node. The beaeon pulse 
may eontain data informing a node that there is eurrently frames buffered awaiting 
delivery and that a station is requested to wake-up. 

Lastly, the beaeon frames allow all assoeiated nodes to maintain synehronization 
to the aeeess point, because eaeh beaeon pulse, which normally is transmitted every 100 
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ms, contains a timestamp of exactly when the beacon frame is sent from the access point. 
Nodes use the timestamp to update and synchronize their clocks to match the access 
point’s clock for the purpose of network management. The timestamp therefore becomes 
an important parameter that is to be used in calculating distances. Figure 20 below is an 
illustration of an 802.11 beacon frame. 



D. LINUX ACCESS POINT 

There is a large variety of commercially available 802.11 access points. Flowever 
many of these access points are operated by proprietary source code embedded in 
firmware that is not readily accessible to the public. It is possible, however, to use Linux 
as a platform that operates as an access point. Because Linux is open source, there is the 
flexibility of tailoring the access point configurations to particular needs, such as 
establishing a firewall, customizing network routing, or instituting NAT. For the purpose 
of this thesis, using Linux makes it much easier to get to the source code responsible for 
extracting link layer beacon information. One of the purposes of this project, then, 
involves configuring Linux and modifying its available support applications to establish 
an access point in order to capture beacon transmission times. Fedora Core version 4, 


31 









was chosen as the Linux platform that is most suited for this projeet beeause of the 
availability of its support applieations. 

E. NETGEAR NETWORK INTERFACE CARD & THE PRISM 54 PROJECT 


The Netgear WG511 network interface eard, Figure 21, was chosen for this 
project because it contains the Intersil Prism GT Duette ISL3890 chipset. Unlike many 
other available ehipsets on the market, sueh as certain models of the Atheros and the Intel 
based chipsets, it is possible to configure the Intersil chipset to work as an infrastructure 
aeeess point. This is because the chipset contains firmware that is responsible for 
generating access point beaeons. 



A driver is necessary to get the Netgear eard to communicate with the Linux 
operating system. The Prism 54 driver was chosen because it provides compatibility for 
the Netgear device and the Fedora Core 4 environment. Additionally, the driver contains 
support for access point funetionalities, namely it manages 802.11 frames that are passed 
to it from the network device. 
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F. LINUX ACCESS POINT SETUP 


Although the project specifically involved three main elements, a Netgear WG511 
card, the Prism54 driver and a Linux Core 4 OS, the subsequent instructions can be used 
in general to setup a customizable access point using any other compatible components. 
For example, it may be possible to us an Intersil based chipset with a HostAP driver 
running on a Linux Debian distribution. 

The setup involved a lot of trial and error because there is much variation in how 
a particular release or distribution of Linux is configured, making this the most difficult 
part of the project. The location of the particular configuration file must be found, the 
parameters modified, and the kernel reset to test if the changes have the correct intended 
effect. Given that kernel source code is about 32 MB in size, compiling it may take as 
much as a couple of hours because process modules have to be built and linked. 
Sources on the Internet may be useful but be aware that instructions may be tailored for a 
particular hardware configuration, which may not be compatible with the Intersil, 
Prism54, Fedora Core 4 configuration. The following is an overview of the setup: 

1. Determine hardware compatibility requirements for the Netgear WG511, 
802.11 b/g wireless devices. 

2. Install Linux Fedora Core 4 with native kernel 2.6.11-1.1369. 

3. Upgrade to Linux kernel 2.6.18 (optional). 

4. Reconfigure 2.6.18 kernel source tree with Full MAC Prism54 support 
using X-configuration utility. 

5. Compile Subversion repository bleeding edge version of the Prism54 
driver using gee and bind to 2.6.18 kernel (optional with 2.6.18). 

6. Compile hostap driver using gee and bind to kernel (optional). 

7. Install driver firmware add-on support, version 1.0.4.3, for 802.11b/g 
Intersil Prism GT-Duette ISL 3890 chipset. 

8. Configure kernel for TCP/IP wireless interface (optional). 

9. Configure 802.11 sehings for wireless interface (optional). 

10. Configure access point to forward packets and route traffic (optional). 
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11. Configure access point as a DHCP server (optional). 

12. Configure access point to forward DNS requests (optional). 


G. THE NETWORK DRIVER 


The network driver acts as interface between the Linux operating system (OS) 
kernel and the hardware network interface card (NIC). When a packet is sent from the 
kernel to the hardware, the network driver is responsible for the commands that toggles 
the correct hardware registers to encapsulate the packet. Additionally it manages the 
radio modulation and signaling of the packet. 

In general, the native kernel cannot feasibly contain enough control commands to 
account for every possible specific detail, of every NIC that is available on the market. 
The driver is designed to be portable and can be loaded into the kernel when a particular 
hardware is chosen. For the more popular models of hardware, various versions of the 
Linux kernel may already have a loadable kernel module driver as part of the kernel 
distribution package, and all that is needed is to bind the driver to the native kernel source 
tree. 

The availability of the driver will determine whether the NIC can be used with 
Linux because the driver is required for the kernel and the hardware to communicate. A 
common mistake is to assume that a Linux driver for any NIC will always be available. 

H. NETWORK INTERFACE CARD CHIPSET 


To determine the availability of the driver, the identity of the hardware must be 
known. Compatibility with a particular driver is a function of the NIC chipset 
manufacturer because each manufacturer has its own proprietary design. In general, 
support for Linux wireless networking is limited. So often time open source groups have 
had to reverse engineer the design of device drivers in order to make a particular wireless 
device compatible with Linux. For example, Netgear does not provide a Linux driver for 
its WG511 NIC, which is based on an Intersil Prism GT Duette ISL3890 chipset. 
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However, the Prism54 group (http://www.prism54.org) has developed an ISL3890 driver 
that when used with a firmware add-on allows deviees with the Intersil Prism GT Duette 
ISL3890 chipset to operate in a Linux environment. To determine the chipset inside, the 
card identification is usually helpfirl. For example, the FCC wireless device search engine 
can be used to locate detailed information about the chipset through the FCC ID number 
located on the back of the device. The manufacturer of the card may have technicians 
who can verily the chipset ID. For PCI devices, the Icpci command will list all connected 
PCI devices, which may include the device identification. In general if the driver is 
already loaded in the kernel, the Network Configuration Tool will indicate the device 
identification. Lastly, doing a Google search for Netgear WG511 generally will reveal 
that it contains the ISL3890 chipset. 

The chipset technology must also be known. For wireless LANs, hardware 
technologies are generally categorized into three groups: a) IEEE 802.11 legacy which 
include 802.11-EH (frequency hopping) and 802.11-DS (direct sequence spread 
spectrum), b) IEEE 802.1 Ib, c) and IEEE 802.1 la and 802.1 Ig. Locating a suitable 
driver then depends on what technology the hardware is using. Eor example the Prism II 
chipsets use 802.1 Ib technology and is compatible with the prism2 driver. The Intersil 
Prism GT Duette ISL3890 chipset however is based on 802.11 b/g technology and is 
compatible with the prism54 driver. Because each chipsets use different 802.11 
technologies the drivers for each chipsets are not interchangeable. 

The Linux driver will depend on what NIC interface is used. ISA, PCI, PCMCIA, 
Cardbus, PLX, USB interfaces, etc. in general will require different drivers. This is 
because the each hardware interface type requires different software instructions related 
to the transfer of data. Eor example there are four different versions of the prism2 driver: 
prism2_cs.o for PCMCIA, prism2_plx.o for PLX, prism2_pci.o for PCI, and 
prism2_usb.o for USB. 

I. FIRMWARE 


The NIC firmware is software that is embedded in the device that includes control 


instructions for the device. It is proprietary microcode that is unique to the device and is 
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stored in read only memory on a semi-permanent storage device. The microcode is 
nonvolatile and may be updated depending on the design of the device. It is more 
common to find NICs on the market that have firmware that is designed exclusively for 
Windows based platforms, therefore without a driver that contains an interface to 
firmware instructions, compatibility between the NIC and Linux is not possible. Some 
chipset manufacturers are unwilling to release the microcode source to open source 
programmers, and the microcode is often protected by copyrights. Therefore in order to 
attain compatibility between a Windows based NIC and a Linux computer, the options 
are to replace the Windows firmware with a Linux microcode, find a Linux driver that 
has a Windows firmware interface, or locate a firmware add-on that when used in 
conjunction with a Linux driver provides an interface to the Windows firmware. 

The firmware add-on allows the device manufacturer to provide support to the 
Linux driver community without directly releasing copyrighted materials. The Linux 
driver community has access to the micro-code source and thus can more readily program 
Linux drivers that can interface with the micro-code. The firmware add-on is not 
firmware but a micro-code extension, meaning the code is loaded every time Linux is 
booted and when the device is present. For the Intersil Prism GT Duette ISL3890 
chipset, the latest firmware add-on release is 1.0.4.3.arm and is obtained from the 
Prism54 project. Figure 22. The firmware add-on is then generally installed in the 
/lib/firmware directory with a path to it annotated in the /etc/hotplug/firmware.agent file 
with FIRMWARE DIR = /lib/firmware. 


36 



PROJECT— 


wvw pnsrr‘>«3 pftj 


I .- I H - : ■ II ■ IL 


Tf>r f uMMAf driver 


■ Nair« TOO'’ 

■ Wiki 


Tbifc driver mdudsd ir ttie etoeb bnus l•8rnal, ac 'pr'i(mS4 Vttt irtablA it'ia oanfiguration optvn. 
If you >M4nt th« bleodiOQ e<:i«)e varcion^ tbe Subvoriicn ropoortoirr it loceted hen> 


IRf 


<iprism54 on Frernod** 

rot nt^t usft otnciai, prtjprietarir l :i firmware yyftn tt.is dt'wer* 
Yot can download from he^re . 

> Version 1. 0.4.3 (fer 13.3880 and T8L3890} 

> Veroloii 1.1.0.0 <for 13.3877) 


^uut>»>rii *0 dtfvkei. 

OnJp RCI cend» wrth nn 1SL3677, )SL'3680 and ISL3890 wrl: Th» h^mi davicas a'tb «n |'5L3086^ l-ncNri 
"rhnmac* ara nd j'jppor+wd If f ou ha'»^ on* of lhi*y» dnvi^^s, or rf you f»ave «n US& card, jou» 

r>irfaw«rw_ 


Figure 21. Intersil Prism GT Duette ISL3890 Chipset Firmware Add-On 


J. LINUX LOADABLE KERNEL DRIVERS AND COMPILING THE 
KERNEL 


The Linux kernel may already have the driver module sources as part of the base 
kernel package. Once the correct driver is determined for the chipset, check the kernel 
configuration files to see if the driver sources are available. If they are present, 
configuration involves enabling the driver that is needed and recompiling the kernel. The 
make xconfig utility. Figure 23, is a GUI based configuration utility that provides the 
capability to pick and choose the modules that are needed. 
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Figure 22. make xconfig Configuration Utility 


During the configuration, an option of choosing whether the module is a loadable 
kernel module or a module that is permanently bound to the kernel is provided. A ‘Y’ 
response indicates that the module is to be bound to the kernel, an ‘M’ response indicates 
that the module is to be a loadable kernel module and an ‘N’ response indicates that the 
module is not desired. Once the desired configuration is chosen, compile the base kernel 
using make bzimage. make bzimage is a utility that compiles and creates a compressed 
binary image of the base kernel which is executed when Linux boots. After the kernel 
image is created the loadable kernel modules must be built with the make modules utility, 
which is used to compile the driver module source codes. What results from this 
procedure is a large number of compiled object files with .o extensions that were chosen 
during the configuration step above. These files need to be moved to the directory where 
the kernel will be able to locate them, which normally is the /lib/modules directory. Use 
the make modules install utility to move these object files to this directory. 
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K. EXTERNAL DRIVER MODULES 


If the driver module is not part of the kernel paekage, the Linux kernel needs to be 
modified by adding the souree eode of the driver to the Linux kernel souree tree and 
eompiling the kernel using the proeedures above. The driver souree eode generally 
eontains a Makefile, which is basically a configuration file that is run by the make utility. 
The make utility uses the Makefile to locate the driver and kernel source files, to compile 
and link the code and to create an executable binary that the OS can use. The 
KERNEL ?ATH parameter within the Makefile may have to be modified, in order for 
the make utility to locate the correct path to the kernel source files. As above the make 
utility creates an object file which is installed into the appropriate directory using the 
make install utility. 

L. LOADING THE MODULES 


If the modules were configured as loadable modules, they can be loaded using the 
modprobe and insmod utilities. The Linux kernel modules can be explicitly loaded using 
the rmmod command. A loaded module can be thought of as being a complete part of the 
base kernel and its rights and privileges to OS resources are managed directly by the base 
kernel. This means if the modules are poorly coded, a loaded module may cause the 
kernel to crash similar to any other statically or demand loaded kernel modules. The 
module object files are re-locatable, meaning the files are not linked to run from a 
permanently assigned address. This makes it possible for the kernel to link to the object 
files on demand, using the modprobe and insmod utilities. 

M. WIRELESS CONFIGURATIONS 


Configuration of the wireless device parameters can be done by modifying script 
files directly or using the iwconfig utility, Eigure 24. The script files are generally located 
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in /etc/sysconfig/network-scripts directory. WEP keys are stored in the keys file under the 
same directory path. 


DEVICE=ethl 
ONBOOr=yes 
BOOTPROTO=none 
lPAUDk=192.168.0.111 
NETMASK=255.255.255.0 
GATEWAY = 192.168.0.254 
DOMAIN- 

DHCP_HOSTNAME= 

HWADDR=00:09:5B:C5:D6;2C # Mac Adress of the wg511 card ! 

TVPE-Wireless 

USERCTL=no 

PEERDNS=yes 

IPV6INrr=no 

ESSID=HomeNetwork 

CHANNEL=12 

MODE=Auto 


Figure 23. ifconfig Script File 


Alternatively, the iwconfig utility, Figure 25, can be used with the switches essid, 
mode, and key to set the basic parameters that are needed to establish a wireless 
connection. 


lo no wireless extensions. 

ethO no wireless extensions. 

ethl IEEE 802.11b/g ESSID:"HomeNJetwork" 

Nickname:"my.laptop.int" 

ModeiAuto Frequency;2.402GH^ Access Point; 
00:09:5B;F8r40;54 

Bit Rate:54Mb/s Tx-Power=31 dBm Sensitivity=20/200 
Retry min limit:8 RTSthr:2347B Fragment thr:2346 B 
Encryption key:50DE-B536-5EFD-D5BB-3879-A908-D8 Security 
mode; restricted 

Link Quality:174/0 Signal level:-30 dBm Noise level:-200 dBm 
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 
Tx excessive retries:o invalid misc:o Missed beacon:o 


Figure 24. iwconfig Fltility 
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N. NETWORK CONFIGURATIONS 


Network parameters are eonfigured using the script files to change static IP 
addresses, the network mask, and the gateway and domain names. To establish DHCP 
services use the dhclient utility. IP routes can also be established if the Linux computer is 
to be used as a router. If the computer is to be used as an access point the NIC must have 
a chipset that is bridging capable. For example, the iwconfig ethl mode Master option 
allows the computer to serve as an access point, using ethl as the wireless interface. 

O. PRISM 54 BEACON ROUTINE 


The Prism54 driver contains the instructions that control the sending of network 
beacons. The complete source code for the bleeding edge driver is available on the 
Subversion directory website (http://svnweb.tuxfamily.org/). The source code is divided 
into a number of different functions: 

1. pci dev: Device Interrupt Handler, Network Interface Control & 
Statistical functions, and Network device configuration functions. 

2. pci_eth: Network Interface functions. 

3. pci hotplug: Module initialization functions. 

4. pci_38xx: Device Interface & Control functions. 

5. ap: PIMFOR netdev interface (Proprietary Intersil Mechanism For Object 
Relay). PIMFOR is a simple request-response protocol used to query and 
set items of management information. 

6. ioctl: allows the code to manage communications with the device driver 
outside the typical read/write operations of data. 

7. wds: Wireless Distribution System allows for the establishment of 
interconnected access points through wireless connections. It is an IEEE 
802.11 protocol that allows for expansion of a BSS without relying on a 
wired backbone. 
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8. oid mgt: Converts between ehannel and freq. 

The eode of interest, however, is loeated in the ioetl funetion, whieh is responsible 
for variety of deviee-speeifie eontrol purposes, ineluding the beaeon management frames. 
The following pieee of eode is responsible for the beaeon or probe response payload 
header, depending on whether the station is serving as an aeeess point or as a wireless 
elient. The probe response is a reply from the wireless elient that ineludes the station’s 
speeifie parameters and its supported data rates. 

/* Beacon/ProbeResp payload header */ 
struct ieee80211_beacon_phdr { 
u8 timestamp[8]; 
ul6 beacon Jnt; 
ul6 capabjnfo; 

} _ attribute _ ((packed)); 

In the event the station is a elient, reeeived beaeons are proeessed to extraet BSS 
information belonging to the aeeess point or peer station operating in ad-hoe mode: 

static void 

prism54_process_bss_data(islpci_private *priv, u32 oid, u8 *addr, 
u8 *payload, sizej len) { 
struct ieee80211_beacon_phdr *hdr; 
u8 *pos, *end; 
if (!priv->wpa) 
return; 

hdr = (struct ieee80211_beacon_phdr *) payload; 
pos = (u8 *) (hdr + 1); 
end = payload + len; 
while (pos < end) { 

if (pos + 2 + pos[l] > end) { 
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printk(KERN DEBUG "Parsing Beacon/ProbeResp failed" 


"for "MACSTR "\n", MAC2STR(addr)); 
return; } 

if(pos[0] == WLAN_EID GENERIC &&pos[l] >= 4 && 
memcmp(pos + 2, wpa_oid, 4) == 0) { 
prism54_wpa_ie_add(priv, addr, pos, pos[l] + 2); 
return; } 

pos += 2 + pos[l]; } } 

In order to configure the wireless station to work as an access point it is necessary 
to use the wireless utilities to establish Master mode. The following piece of code 
switches the wireless device into Master mode; 

prism54_set_mode (struct net_device *ndev, struct iw_request_info *info, 

_ u22 * uwrq, char *extra) { 

islpci_private *priv = netdev_priv(ndev); 

u32 mlmeautolevel = CARD DEFAULT_MLME_MODE; 

if ((*uwrq == IW_MODE MASTER) && (priv->acl.policy != 

MACPOLICYOPEN)) 

mlmeautolevel = DOTll_MLME_INTERMEDIATE; 

P. CALCLULATING DISTANCES USING LAYER TWO FRAMES 


The stats timestamp parameter may be the key to being able to effectively 
calculate distances using layer two frames: 

struct iw_statistics * 

prismS4_get_wireless_stats(struct net_device *ndev) { 
islpci_private *priv = netdev_priv(ndev); 

/* If the stats are being updated return old data */ 
if (down _trylock(&priv-> stats_sem) == 0) { 
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memcpy(&priv->iwstatistics, &priv->localJwstatistics, 
sizeof (struct iw_statistics)); 

/* They won't be marked updated for the next time */ 
priv->local_iwstatistics.qual.updated = 0; 
up(<Scpriv-> stats _sem); 

} else 

priv-> iwstatistics. qual. updated = 0; 

/* Update our wireless stats, but do not schedule to often 
* (max 1 HZ) */ 

if ((priv->statsJimestamp == 0) || 

time_after(jiffies, priv->statsJimestamp + 1 * HZ)) { 
schedule_work(&priv-> stats _work); 
priv-> stats Jimestamp = jiffies; } 

return &priv->iwstatistics;} 

Modification of the wireless client driver and the aecess point driver is neeessary 
in order to properly capture correct round trip frame times. A possible modifieation 
would involve having the wireless client automatieally send back a probe response 
whenever it receives a beaeon from the aecess point. The aceess point having kept track 
of its initial beacon timestamp calculates the difference in time between the initial 
timestamp and when it receives the return probe response from the client. The difference 
in time would then be eorrelated to: 

RTT = Total Time = Proc 1 + Proc 2 + Prop 1 + Prop 2 

Beeause the beaeons and probe responses are being proeessed as layer two 
frames, it is expeeted that total proeessing times (Proe 1 and Proe 2) will be substantially 
redueed. 
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V. SIGNAL STRENGTH 


A. SIGNAL STRENGTH UNITS OF MEASURE 


802.11 signal strengths are often reported in units of milliwatts (mW), db- 
milliwatts (dBm), Reeeived Signal Strength Indicator (RSSl), or percentage values. Once 
one value is known, the other values can be calculated through simple conversion 
methods. For example, dBm can be converted from mW through the following relation: 

dBm = 10 * log (mW) 

RSSl values are arbitrarily assigned by the device manufacturer and are based on 
the device’s most practical range of power. RSSl values range from 0-255 or the range 
represented by 1 byte, but manufacturers can subjectively choose RSSl ranges anywhere 
between 0 and 255. For example, CISCO chooses to correlate RSSl 0, the device’s 
reception threshold sensitivity, to -96dBm and RSSl 100, the device’s highest signal 
strength value, to -20 dBm, even though signal strengths may extend up to or beyond 20 
dBm. RSSl values are chosen because wireless devices are not truly capable of 
measuring 0% signal strengths. This is because it is incapable of telling the difference 
between an environment with completely no signal and an environment with a signal but 
no packets being transmitted. Additionally, since a typical wireless access point power 
drops below -20 dBm at 5 feet, it is practical and reasonable to assign 100% signal 
strength to a measured power of -20 dBm. 

Percentage values are assigned relative to RSSl values. For example, 
Netstumbler signal strength meters have an RSSl range of 0-50. RSSl 0 therefore 
corresponds to 0%, RSSl 25 corresponds to 50% and RSSl 50 corresponds to 100% 
signal strengths. 

Figure 25 is a graphical representation of the relationship between the various 
units of measure for signal strength. 


45 



Maximum Effective Range 

A 


CISCO RSSI Most Practical Range 




dBm: 

-96 dBM 

-20 

2D 

Watts: 

2.5 X 10 ^“mW 

.01 

100 

CISCO RSSI: 

0 RSSI 

100 


CISCO o/o: 

0 o/o 

100 



Figure 25. Signal Strength Units of Measure 


RSSI correlates distance based on received power levels. Since the wireless 
nodes already have radios for communication, RSSI is a low-power method of measuring 
distance at almost no computational cost. Thus, measuring distance through RSS is 
highly desirable as the existing hardware can be used, mobile nodes can perform the 
calculations independently, and deployment is simple. 

B. “INVERSE-SQUARE” RELATION 


Power loss over the air, given constant atmospheric conditions, follows the 
inverse square law: 


Power a 1 / distance^ 


Receiver threshold sensitivity is approximately 2.5 x 10"'° mW for a typical 802.11 
wireless card. If a transmitter is located at the center, the surface area of the sphere can 
be used to approximate power at a given distance from the transmitter. This is because 
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power is omni-directional and is therefore proportional to the surface area of a sphere, 
47ir^. Distance from the transmitter is then the radius of the sphere. The inverse relation 
is due to the loss of power as you move further from the transmitter. Because of this 
relationship, the following signal strength graph is expected. Figure 26; 



Figure 26. Signal Strength (dBm) vs Distance (ft) 

Once the data is extrapolated, determination of distance can be achieved by cross 
referencing signal strength values from the graph. 

C. METHODOLOGY 


RSSI values are used to determine a mobile node’s distance from an access point. 
Because of the inverse relationship between power and distance, it is possible to produce 
a signal strength map through systematic sampling of the environment. The first step in 
RSSI-based localization is estimating the distance between two nodes, given the signal 
strength received by one wireless node from the other. A signal strength-distance 
correlation graph is created using various locations where signal strengths are measured 
and recorded. The correlation map is extrapolated from a finite set of collected 
measurements and is used as a reference to predict actual distance values. Because signal 
strengths fluctuate, sometimes with large deviations due to ambient conditions and noise, 
it is important to ensure that environmentals are the same when correlating distances to 
signal strengths. For example, with Linux-based systems, the iwconfig utility includes 
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functionality to measure noise which can be used to eliminate signal strength 
measurements taken under high noise conditions. An algorithm can be used to automate 
this proeess. Signal strength values that have a noise value above a certain threshold are 
removed, while those values obtained under lower noise conditions are given higher 
weightings in the caleulations process. Once a signal strength mapping is determined, 
signal strengths are cross-refereneed to the eorrelation map to calculate distanee. If the 
signal strength measures exhibit good preeision and accuracy, it may be possible to 
determine positions using distances taken from the signal strength map. 

The test bed is eomprised of one Dell Celeron mobile laptop eonfigured with 
Linux Fedora Core 4 running as an aceess point using a Netgear WG511 wireless eard 
rated at 31 dBm maximum effective transmit power. An additional Dell Celeron wireless 
client, configured with Linux Fedora Core 4, was used running the native supplicant. 
The access point was placed at home base on a softball field. Using the Linux client and 
the iwconfig utility, signal strength values were captured at 25 ft intervals from the access 
point. Figure 27. Thirty signal strength measurements were taken at each location and 
averaged. These measurements were then plotted against distance from the aeeess point 
and best fit line extrapolated through the data points. 



Figure 27. Signal Strength Measured at 25 ft Intervals from Access Point 
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A typical 802.11 wireless device has a rated output of 100 mW. Although not 
perfectly accurate because of power losses through the transmitter device, it can be 
assumed for simplicity that you see 100 mW of power at the tip of the device antenna. 

Eleven positions were selected to perform range estimations. For each position, 
signal strength measurements were taken. The iwconfig tool was used to extract RSSI 
values. Figure 28. Measurements of RSSI values were then imported into Excel for 
statistical analysis. 


lo no wireless extensions, 

etho no wireless extensions. 

ethl IEEE 802.11b/g ESSID:’’HomeNetwork" 

Nickname:”my.laptop.int" 

Mode:Auto Frequency:2.AGSGHz Access Point: 
00:09:5B:F8:40:54 

Bit Rate;54Mb/s Tx-Power=31 dBm Sensitivity =20/200 
Retry min limit:8 RTS thr:2347 B Fragment thr:2346 B 
Encryption key: 50DE-B536-5EFD-D5BB-3879-A9O3-D8 Security 
mode: restricted 

Link Quality: 174/0 Signal level:-30 dBm Noise level:-200 dBm 
Rx invalid nwidrO Rx invalid crypt:0 Rx invalid frag:0 
Tx excessive retriesrO Invalid misc:0 Missed beacon:0 


Figure 2 8. Finux ’ s iwconfig 


A second set of measurements was taken from the access point to 10 meters. 
Beeause the inverse-square relation states that RSSI values exponentially deereases with 
increasing distance, it was necessary to capture signal strength values close to the access 
point. In doing so, distance resolution is more accurate and precise because, near the 
access point there is a large change in RSSI for every given change in distance. Again, 
both laptops were configured to run in ad-hoc mode. With iwconfig running, received 
signal strengths were measured in increments of 1 meter. 

Once the grid map is finalized, signal strength is equated to distance. To 
automate signal strength measurements, a bash seript, iwDistance.sh, was implemented 
using Perl. 
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while [1=1] 

do sleep 1 iwconjig 2> /dev/nuU \ perl iwParse.pl 

done 

This shell script executes iwconfig every second. The output is blanked and piped 
to iwParse.pl. iwParse.pl is designed to parse iwDistance.sh’s output and extract the 
dBm value. For iwParse.pl to work properly, the upper and lower limits of the RSSI of a 
particular location have to be determined. 

while (<STD1N>) { 

(SdBmValue) = ($_ /Tx-Power=(.*?) dBm/); 

if (SdBmValue >=30 && SdBmValue < 40) {print "10feet\n"} 
#more conditional statements } 


D. RESULTS 


In order to establish the reliability of received signal strength readings, a value of 
95% was assigned to the confidence interval. By doing so, the upper and lower limits of 
the received signal strengths at a particular distance could then be determined. This value 
was chosen so that once the upper and lower limits were incorporated in iwParse.pl, its 
output will be more accurate as there will be a 0.95 probability that the confidence 
interval would contain the population mean. 

RSSI was measured in increments of 25 feet and plotted versus distance. Figures 
29 and 30. 
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Distance (ft) average Signal Strength (dBm) Power (mW) 


25 

-63 

5.01E-07 

50 

-72 

6.31E-08 

75 

-67 

2.00E-07 

100 

-68 

1.58E-07 

125 

-66 

2.51E-07 

150 

-72 

6.31E-08 

175 

-73 

5.01E-08 

200 

-69 

1.26E-07 

225 

-74 

3.98E-08 

250 

-76 

2.51E-08 

275 

-75 

3.16E-08 


Figure 29. Signal strength measurements 



Figure 30. Signal strength versus distance, 25 to 275 ft. 
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From Figure 30, a decline in signal strength is noticeable. The apparent decrease 
in signal strength seems to follow the trend predicted by the inverse-square law. It was 
expected that a decrease in signal strength value will occur as the mobile client is moved 
away from the access point. However from the results it is not possible to accurately 
resolve distances using signal strengths taken at positions greater that 25 ft from the 
access point because RSSI changes so little for every given unit change in distance. 
Using the wireless devices in this setup, it is impossible to accurately resolve distances 
beyond 25 ft due to the limitations of the gear. 

The following shows the results of signal strength measurements taken at 
distances less than 10 meters from the access point. Figure 31. 


Distance (m)Average Signal strength (dBm) Power (mW) Lower Limit Upper Limit 


1 

-44.13333 

3.86071E-05 

-44.36 

-43.91 

2 

-57 

1.99526E-06 

-57.36 

-56.64 

3 

-69.4 

1.14815E-07 

-69.73 

-69.07 

4 

-69.8 

1.04713E-07 

-70.16 

-69.44 

5 

-66.1 

2.45471E-07 

-66.97 

-65.23 

6 

-70.6 

8.70964E-08 

-71.68 

-69.52 

7 

-76.53333 

2.22161E-08 

-77.53 

-75.54 

8 

-78.3666 

1.4566E-08 

-78.81 

-77.92 

9 

-76.13333 

2.43594E-08 

-76.62 

-75.65 

10 

-74.36666 

3.65876E-08 

-74.70 

-74.03 


Figure 31. RSSI at distances less than 10 meters from access point 

Within 1 to 3 meters, for every 1 meter change in distance there is a large change 
in RSSI, Figure 32. The change in RSSI values are large enough that for the wireless 
gear used in this setup, it is possible to accurately resolve distances. However, there are 
overlaps between the upper and lower limits of the received signal strength established by 
the 95% confidence interval for each pre-determined location. Thus, it is practically 
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impossible for iwParse.pl to determine the wireless node’s position once the node’s 
distance from the access point exceeds 3 meters. 


Signal Strength Measurements 



-♦— average Signal Strength Lower Limit A Upper Limit 


Figure 32. 


Signal strength versus distance, 1 to 10 meters 
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VI. CONCLUSIONS 


A. ROUND TRIP TIMES 


The time it takes to send data over an 802.11 backbone can be used to determine 
positioning information between the clients and access points on the network. However, 
using round trip times to effectively determine distances highly depends on the 
processing time of the client-server pair and the propagation time of the radio signal over 
the air. For RTFs obtained through layer three packet transmissions, the processing times 
are too high to yield any information of value. Observed layer three total time, the packet 
processing and packet round trip propagation time, for a 200 meters setup is on the order 
of 1 ms with a standard deviation of 80 ps. The physical properties of radio signal 

o 

transmissions over the air defines the speed of the radio signal as 3 x 10 m/s, or as a unit 
of data travels one meter in 3.33 ns. Therefore for every change in one meter of distance 
there is a corresponding change of 6.66 ns in round trip propagation time. For 200 
meters, it takes a signal 1.33 ps to complete a round trip from a client to the server and 
back. Because the standard deviation is nearly 80 times greater than the round trip 
propagation time for a layer three packet to travel 200 meters, any changes in round trip 
time that arises due to a change in distance between the client and server, is easily 
overwhelmed by the deviations that result from conducting measurements. 

Layer two frames may provide a solution to effectively using round trip 
propagation times as a way in obtaining distance. One possible method involves using 
802.11 beacon frames. Because beacons are a link layer entity, much of the processing 
time it takes to package data is eliminated. When compared to data that originates from 
the application layer or any layer that is above layer two, there is a significant time 
premium that is saved by using layer two frames. Take for example a typical CPU 
operating at 1 GHz. A single instruction would at its best take 1 ns to complete. 
Assuming the processor is running a typical 50 processes, it would take 50 ns before the 
data unit can be serviced, if each process is a composed of a single instruction. As the 
data unit moves down the protocol stack, additional processing occurs. How much 
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processing time is added to total time measurements is therefore a function of how many 
instructions there are, how many proeesses are running and how fast the proeessor is 
running. Additionally, if the data originates higher up in the protoeol stack, processing 
time depends on what type of hardware is servieing the instruction at the particular layer. 
For example, the applieation layer is serviced by the main CPU, the network layer is 
serviee by the router CPU, and the link layer is servieed by the chipset embedded in the 
wireless card. By working with link layer frames, proeessing times from the main CPU 
and the router CPU is eliminated. Therefore, in order to be able to resolve changes in 
distanee of one meter, the deviations in total proeessing time needs to be less than 6.66 
ns, the time it takes a radio signal to complete a one meter round trip propagation path. 
Using link layer frames will lower total proeessing time measurements whieh will lead to 
lower processing time deviations, possibly achieving the nanoseeond threshold. If this 
holds true, measuring distances using 802.11 signals will be possible. 

B. SIGNAL STRENGTHS 


Using signal strengths is an alternative means of wireless elient positioning. The 
inverse square law defines the physical properties of wireless signal strengths and can be 
used to calculate distanee through extrapolation of a signal strength versus distance 
graph. 

Given the low power ratings for the typical wireless card and wireless access 
point, the data does not suggest that a robust method of client location is possible for the 
typical 802.11 wireless deviees using signal strengths and the inverse-square power 
relation. However modifications to the wireless hardware may make positioning, 
throughout a larger distance range, possible, if the devices’ transmit power can be 
inereased such that there is a power distribution that extends further from the 
transmission source. The typical 802.11 wireless deviee transmits at a power level rated 
between 10 mW to 50 mW, or 10 dBm to 17 dBm, which corresponds to approximately 
200 meters maximum effective range. Near the transmission source and within 5 meters, 
the signal strength power distribution drops off significantly as a function of distance as 
the client moves away from the souree. At this range, there is an advantage for client 
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location because for every small ehange in distanee, there is a eorresponding large ehange 
in signal strength, which can easily be detected. The problem, however, is that beyond 3 
meters there is little resolution of distanee because the inverse square curve levels off 
beginning at 3 meters. That is, for a signifioantly notieeable change in signal strength, 
there needs to be a large change in distanee. Any small ehange in distanee, sueh as one 
meter, whieh is a reasonable performanee requirement, would go unnotieed. 

Inereasing the souree hardware transmit power is a possible solution to generating 
an inverse square distribution that is more robust. If the “heel” of the eurve, the area of 
the eurve where power begins to level off, ean be extended beyond 3 meters, elient 
loeation using signal strengths may offer some signifieant advantages. Various wireless 
eomponents are available with power ratings that are mueh higher than typieal FCC 
eompliant 802.11 hardware. For example, SMC Networks offers a wireless PC Card that 
transmits at a power rating that is twiee the power rating of a standard commereially 
available wireless eard. Aeeording to the eompany, the SMC 2532W wireless eard 
transmits at 200 mW, or 23 dBm, whieh translates to a maximum effective range that 
extends beyond 800 meters. The SMC 2532W works with the Linux aceess point 
eonfiguration beeause it eontains the Intersil ehipset, whieh is eompatible with Fedora’s 
Prism54 driver and firmware add-on. 

Another possible solution involves using a direetional antenna. Figure 33, to foeus 
the wireless deviee’s RF pattern so as to aehieve higher antenna gain. Using direetional 
antennas offer signifieant performanee improvements, on the order of a two to eight 
times, eorresponding to a 3dB to 9dB inerease in gain. 
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Figure 33. Directional Antenna. 

Figure 34 illustrates a typical radiation pattern for an omni-directional antenna. 



By decreasing the antenna’s beam width, energy is concentrated in a particular 
direction of interest. As a result there is higher density of power directed along a 
particular vector, as shown in Figure 35. 


58 












Figure 35. Decreasing antenna beam width. 
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APPENDIX A. CLIENT SERVER SOURCE CODE 


A. CLIENT ROUTINE 

import java.lang. *; 

import java.io.*; 
importjava.net.*; 
import j avax. swing. *; 
import j avax. swing. JFrame; 
import java.util.Random; 
import j ava .util. Tree Set; 
import or.util.SimpleStats; 
import graph.Histogram; 
public class NanoClient { 

public static void main( String args[] ) { 

SimpleStats ss = new SimpleStats(); 

Histogram hist = new Histogram ("Output", 0, 2600000, 100); 
for (int i=0; i <= 1000; i++) { 

// UDP CLIENT ROUTINE 
try { 

DatagramSocket clientSocket = new DatagramSocket(); 
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InetAddress IP Address = InetAddress.getByName(" 127.0.0.1"); 


byte[] sendData; 

byte[] receiveData = new byte[548]; 

// UDP SEND 

System.out.println ("Sending packet!"); 

String sentence = "welcome!"; 
sendData = sentence.getBytes(); 

DatagramPacket sendPacket = 

new DatagramPacket(sendData, sendData. length, 
IP Address, 9876); // UDP IP address and Port Number 
clientSocket.send(sendPacket); // Send Packet 
long start = System.nanoTime(); 

System.out.println (start); // Start Timer 
// UDP RECEIVE 
DatagramPacket receivePacket = 

new DatagramPacket(receiveData, 
receivcData.length); 
clientSocket.setSoTimeout( 1000); 
clientSocket.receive(receivePacket); 
long stop = System.nanoTimeO; 
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System.out.println (stop); // Stop Timer 


long differenee = stop-start; 

System.out.println (differenee); // Differenee 
//if (differenee > 0.0 && differenee < 600000.0) { 
ss.newObs (differenee); 
hist.update (differenee, true); 

//} 

String reestring = 

new String(reeeivePaeket.getData(), 0, reeeivePaeket.getLength()); 
System.out.println("FROM SERVER;" + reestring); 

// UDP CEOSE SOCKET 
elientSoeket.closeO; } 
eateh (Exception error) { 

System.out.println ("\nCould not establish a UDP connection!!"); 

System, exit (0); } 

} 

System.out.println ("Mean: " + ss.sampleMean( )); 

System.out.println ("STD: " + Math.sqrt(ss.sampleVariance( ))); 

} // end main 

} 
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B. SERVER ROUTINE 


import java.io.*; 
importjava.net.*; 
import j avax. swing. JFrame; 
class NanoServer { 

public static void main (String [] args) throws Exception { 

DatagramSocket serverSocket = new DatagramSocket(9876); // Port Number 
while (true) { 

System.out.println ("UDP Server waiting for connection...."); 
byte[] receivcData = new byte[548]; 
byte[] sendData; 

// Receive Packet 
DatagramPacket receivePacket = 

new DatagramPacket(receiveData, receivcData.length); 
serverSocket.receive(receivePacket); 

String recstring = new String( 

receivePacket.getDataO, 0, receivePacket.getLength()); 

InetAddress IP Address = 
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receivePacket.getAddressQ;// get sending IPAddress 


int port = reeeivePacket.getPortO; 

String entry = recstring;// Server sends 
sendData = entry.getBytes(); 

DatagramPaeket sendPaeket = 

new DatagramPacket(sendData, sendData.length, 
IPAddress, port); // set to IP Address 
serverSocket.send(sendPaeket); 

} 

} 

} 
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APPENDIX B. RF POWER CONVERSION TABLE 


dBm 

Volts 

Watts 

75 dBm 

1257.43 V 

31.62 kW 

74 dBm 

1120.69 V 

25.12 kW 

73 dBm 

998.81 V 

19.95 kW 

72 dBm 

890.19 V 

15.85 kW 

71 dBm 

793.39 V 

12.59 kW 

70 dBm 

707.11 V 

10.00 kW 

69 dBm 

630.21 V 

7.94 kW 

68 dBm 

561.67 V 

6.31 kW 

67 dBm 

500.59 V 

5.01 kW 

66 dBm 

446.15 V 

3.98 kW 

65 dBm 

397.64 V 

3.16 kW 

64 dBm 

354.39 V 

2.51 kW 

63 dBm 

315.85 V 

2.00 kW 

62 dBm 

281.50 V 

1.58 kW 

61 dBm 

250.89 V 

1.26 kW 

60 dBm 

223.61 V 

1.00 kW 

59 dBm 

199.29 V 

794.33 W 

58 dBm 

177.62 V 

630.96 W 

57 dBm 

158.30 V 

501.19 W 

56 dBm 

141.09 V 

398.11 W 

55 dBm 

125.74 V 

316.23 W 

54 dBm 

112.07 V 

251.19 W 
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53 dBm 

99.88 V 

199.53 W 

52 dBm 

89.02 V 

158.49 W 

51 dBm 

79.34 V 

125.89 W 

50 dBm 

70.71 V 

100.00 W 

49 dBm 

63.02 V 

79.43 W 

48 dBm 

56.17 V 

63.10 W 

47 dBm 

50.06 V 

50.12 W 

46 dBm 

44.62 V 

39.81 W 

45 dBm 

39.76 V 

31.62 W 

44 dBm 

35.44 V 

25.12 W 

43 dBm 

31.59 V 

19.95 W 

42 dBm 

28.15 V 

15.85 W 

41 dBm 

25.09 V 

12.59 W 

40 dBm 

22.36 V 

10.00 W 

39 dBm 

19.93 V 

7.94 W 

38 dBm 

17.76 V 

6.31 W 

37 dBm 

15.83 V 

5.01 W 

36 dBm 

14.11 V 

3.98 W 

35 dBm 

12.57 V 

3.16 W 

34 dBm 

11.21 V 

2.51 W 

33 dBm 

9.99 V 

2.00 W 

32 dBm 

8.90 V 

1.58 W 

31 dBm 

7.93 V 

1.26 W 

30 dBm 

7.07 V 

1.00 W 

29 dBm 

6.30 V 

794.33 mW 

28 dBm 

5.62 V 

630.96 mW 

27 dBm 

5.01 V 

501.19 mW 
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26 dBm 

4.46 V 

398.11 mW 

25 dBm 

3.98 V 

316.23 mW 

24 dBm 

3.54 V 

251.19 mW 

23 dBm 

3.16 V 

199.53 mW 

22 dBm 

2.82 V 

158.49 mW 

21 dBm 

2.51 V 

125.89 mW 

20 dBm 

2.24 V 

100.00 mW 

19 dBm 

1.99 V 

79.43 mW 

18 dBm 

1.78 V 

63.10 mW 

17 dBm 

1.58 V 

50.12 mW 

16 dBm 

1.41 V 

39.81 mW 

15 dBm 

1.26 V 

31.62 mW 

14 dBm 

1.12 V 

25.12 mW 

13 dBm 

1.00 V 

19.95 mW 

12 dBm 

890.19 mV 

15.85 mW 

11 dBm 

793.39 mV 

12.59 mW 

10 dBm 

707.11 mV 

10.00 mW 

9 dBm 

630.21 mV 

7.94 mW 

8 dBm 

561.67 mV 

6.31 mW 

7 dBm 

500.59 mV 

5.01 mW 

6 dBm 

446.15 mV 

3.98 mW 

5 dBm 

397.64 mV 

3.16 mW 

4 dBm 

354.39 mV 

2.51 mW 

3 dBm 

315.85 mV 

2.00 mW 

2 dBm 

281.50 mV 

1.58 mW 

1 dBm 

250.89 mV 

1.26 mW 

0 dBm 

223.61 mV 

1.00 mW 
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-1 dBm 

199.29 mV 

794.33 uW 

-2 dBm 

177.62 mV 

630.96 uW 

-3 dBm 

158.30 mV 

501.19 uW 

-4 dBm 

141.09 mV 

398.11 uW 

-5 dBm 

125.74 mV 

316.23 uW 

-6 dBm 

112.07 mV 

251.19 uW 

-7 dBm 

99.88 mV 

199.53 uW 

-8 dBm 

89.02 mV 

158.49 uW 

-9 dBm 

79.34 mV 

125.89 uW 

-10 dBm 

70.71 mV 

100.00 uW 

-11 dBm 

63.02 mV 

79.43 uW 

-12 dBm 

56.17 mV 

63.10 uW 

-13 dBm 

50.06 mV 

50.12 uW 

-14 dBm 

44.62 mV 

39.81 uW 

-15 dBm 

39.76 mV 

31.62 uW 

-16 dBm 

35.44 mV 

25.12 uW 

-17 dBm 

31.59 mV 

19.95 uW 

-18 dBm 

28.15 mV 

15.85 uW 

-19 dBm 

25.09 mV 

12.59 uW 

-20 dBm 

22.36 mV 

10.00 uW 

-21 dBm 

19.93 mV 

7.94 uW 

-22 dBm 

17.76 mV 

6.31 uW 

-23 dBm 

15.83 mV 

5.01 uW 

-24 dBm 

14.11 mV 

3.98 uW 

-25 dBm 

12.57 mV 

3.16 uW 

-26 dBm 

11.21 mV 

2.51 uW 

-27 dBm 

9.99 mV 

2.00 uW 


70 





-28 dBm 

8.90 mV 

1.58 uW 

-29 dBm 

7.93 mV 

1.26 uW 

-30 dBm 

7.07 mV 

1.00 uW 

-31 dBm 

6.30 mV 

794.33 nW 

-32 dBm 

5.62 mV 

630.96 nW 

-33 dBm 

5.01 mV 

501.19 nW 

-34 dBm 

4.46 mV 

398.11 nW 

-35 dBm 

3.98 mV 

316.23 nW 

-36 dBm 

3.54 mV 

251.19 nW 

-37 dBm 

3.16 mV 

199.53 nW 

-38 dBm 

2.82 mV 

158.49 nW 

-39 dBm 

2.51 mV 

125.89 nW 

-40 dBm 

2.24 mV 

100.00 nW 

-41 dBm 

1.99 mV 

79.43 nW 

-42 dBm 

1.78 mV 

63.10 nW 

-43 dBm 

1.58 mV 

50.12 nW 

-44 dBm 

1.41 mV 

39.81 nW 

-45 dBm 

1.26 mV 

31.62 nW 

-46 dBm 

1.12 mV 

25.12 nW 

-47 dBm 

1.00 mV 

19.95 nW 

-48 dBm 

890.19 uV 

15.85 nW 

-49 dBm 

793.39 uV 

12.59 nW 

-50 dBm 

707.11 uV 

10.00 nW 

-51 dBm 

630.21 uV 

7.94 nW 

-52 dBm 

561.67 uV 

6.31 nW 

-53 dBm 

500.59 uV 

5.01 nW 

-54 dBm 

446.15 uV 

3.98 nW 
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-55 dBm 

397.64 uV 

3.16 nW 

-56 dBm 

354.39 uV 

2.51 nW 

-57 dBm 

315.85 uV 

2.00 nW 

-58 dBm 

281.50 uV 

1.58 nW 

-59 dBm 

250.89 uV 

1.26 nW 

-60 dBm 

223.61 uV 

1.00 nW 

-61 dBm 

199.29 uV 

794.33 pW 

-62 dBm 

177.62 uV 

630.96 pW 

-63 dBm 

158.30 uV 

501.19 pW 

-64 dBm 

141.09 uV 

398.11 pW 

-65 dBm 

125.74 uV 

316.23 pW 

-66 dBm 

112.07 uV 

251.19 pW 

-67 dBm 

99.88 uV 

199.53 pW 

-68 dBm 

89.02 uV 

158.49 pW 

-69 dBm 

79.34 uV 

125.89 pW 

-70 dBm 

70.71 uV 

100.00 pW 
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